[レポート]サーバーレスアーキテクチャへのChaos Engineeringの原則適用について #reinvent #DVC305

AWS re:Invent 2018

#AWS

#サーバーレス

阿部信介

2018.11.27

この記事は公開されてから1年以上経過しています。情報が古い可能性がありますので、ご注意ください。

サーバーレス開発部の阿部です。

今回一番楽しみにしていたセッション"Applying Principles of Chaos Engineering to Serverless"をレポートします。

概要

大部分のツールではEC2の停止にフォーカスが置かれることが多いことに代表されるように、Chaos engineeringの原則はサーバーレスにフォーカスされていませんでした。 chaos engineeringをサーバーレス環境に適用するために必要な制約とチャレンジについて説明します。

Chaos Engineeringとは

近年のシステムはマイクロサービスやAWSマネージドシステムなど、分散した多数のコンポーネントやサービスで構成されています。それはつまりシステム全体が複雑性に支配されていることであり、コンポーネントレベルでのトラブル発生がシステム全体に及ぼす影響を把握することが困難になっているということです。

Chaos Engineeringとは、これらのシステム(本番です。、に対して「コントロールされた外乱(エラー、サーバ停止など)」を実験的に引き起こして回復力などを検証するための技法です。 Netflixで実施されていることで一躍脚光を浴びました。Simian Armyと呼ばれる各種ツールが公開されています。また、国内ではクックパッドさんの取り組みがブログで触れられています。

Principles of Chaos Engineering カオスエンジニアリングやっていく宣言 Chaos Engineering に向けてレシピサービスの Steady State を追求する

本セッションのスピーカーはDAZNのPricipalエンジニアです。他のセッションのAudibleといいNexflixといい、動画配信系で活発ですね。

principles

Principles of Chaos Engineeringより(当該サイトの日本語訳からの抜粋です)。

定常状態における振る舞いの仮説を立てる
実世界の事象は多様である
本番環境で検証を実行する
継続的に実行する検証の自動化
影響範囲を局所化する

メモ

Chaos Engineering全般について

Chaos Enginerringはシステムに対するvaccination(予防接種)である
- 実際のユーザデータで障害を起こす前に障害を起こして対応を学ぶためのアプローチ
- 目的は壊すことではない
ステップを追う
- 定常状態(steady state)を定義して障害の仮説を立てる
- レイテンシやエラーのインジェクション箇所と影響範囲、リカバリを決める
- 現実に即した障害をインジェクションする(user experience is king)
- 経験はコントロールするために必要なので、ユーザが何をするか知ろう
チームメイトを驚かせるな
- 営業時間に実施する
- 大切なタイミングでは実施しない
障害を扱うので小さくコントロールされたタイミングで実施する
- 小さく扱う
- 最初からProductionでスタートしない
自動化するレイヤとしないレイヤ
- Peopel, Practices, ProcessはGame Daysで。その他のレイヤは自動化する

ServerlessにおけるChaos Engineeringについて

ChaosシリーズはEC2とか今までのアーキテクチャに対するツール
- serverlessだとkillするサーバーないのでアプローチが変わる
- 各ファンクションでリソース/設定/エラーモードを持つので個別にインジェクションする仕組みが必要
- インフラレイヤがコントロールできない、何が起こっているかわかってもできることがほとんどない
サーバーレスアーキテクチャで共通する弱点
- 複数のAPIの連携途中で落ちる
- 利用している他のマネージドサービスで落ちる
タイムアウトを決めるのは難しい(長すぎても短すぎても)
- ケースが多すぎて追いつけなかった、資料公開待ち
- リカバリプロセスを確保した上で動的にタイムアウトを設定する
サーバーレスに共通する障害 * dynamoDBのスループット * HTTP 5XX * Lambdaのスロットル
Serverlessにおける各種インジェクションケース
- ケースが多く、かつ早くて追いつけなかった
- 仮説に基づいてエラーやレイテンシのインジェクション箇所と計測箇所を定義
- Lambdaのスロットルは一時的に環境で減らす
- エラーやレイテンシのインジェクションは自力でラッパーライブラリを実装
強くなってエラーに負けないようにしよう
- それでもクマには負ける

まとめ

我々も含めて、サーバーレスアーキテクチャで目下よく話題に上がるのはインテグレーションよりも単位が大きなテストのやりづらさです。

BaaSやLamdbaに代表されるFaaSを組み合わせてシステムの全体性を担保するため、クラウド側でしか実行できないことが増えてしまい、個別のコンポーネント単位でしか思うようにテストができません。Lamdbaに関してはソースコードの構造分割などのアプローチによってインテグレーションを進めるアプローチがありますが、システム全体になるとまだその議論は十分ではありません。

Chaos Engineeringはシステム全体の耐障害性を測るためのやり方になりますが、サーバーレスアーキテクチャでは非機能要件やE2Eテストを含めてより重要なアプローチになると思われます。

スライドのスピードが早かったので追いつけてないところがいくつかあります。スライドだけでもlatencyのインジェクションパターンが豊富に記載されていて、レポートでは一つ一つの内容について書ききれないほど非常に内容の濃いセッションでした(セッション中も全て追いつけたわけではないです)。資料が公開されたら読み返したいです。紹介されたケースでは、ラッパーライブラリの自力実装などの力技やアーキテクチャ上の準備など、総じて過渡期の印象を受けました。これからも各社このようなセッションが増えてくると思いますので、キャッチアップしていきたいと思います。

最後にところどころ笑いどころがあったようなのですが、ついていけなかったのが悔しかったです。